home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Grab Bag
/
Shareware Grab Bag.iso
/
009
/
unprot.arc
/
CORNERST.TXT
< prev
next >
Wrap
Text File
|
1986-03-27
|
4KB
|
91 lines
CORNERSTONE UNPROTECTION SCHEME
-------------------------------
The following describes a method of completely unprotecting the hard disk
installation of Infocom's Cornerstone, and a less complete method of
unprotecting future versions which may render the first method obsolete.
The Cornerstone installation process creates a hidden file named
INFOCOM.CNR in the root directory. This file contains two bytes, which
rperesent in encrypted form the cluster number where the file is stored.
When Cornerstone is invoked, the program first checks for the existence of
the hidden file, and then compares the data with the cluster number in the
directory. If the checks fail, Cornerstone looks for a legitimate system
disk in Drive A. At present (Cornerstone version 5.1, which I believe to
be the most current release), this can be completely circumvented by
searching the file mme.exe for the two INT 13's it contains, and NOP'ing
them out.
Specifically, rename a copy of mme.exe to something with a non-exe
extension, e.g. mme.zap. Run debug, and load mme.zap.
Now, at the debug prompt type "s 0 l ffff cd 13<enter>" (without quotes).
Debug responds: XXXX:86C9
XXXX:86E1
(If this is not the case, you have a different version, though if it
detects two INT 13's, it might be worth trying what follows, substituting
the offsets that debug reports to you for those I am using.)
Type: e 86C9<return>
Debug responds: CD.
Type: 90<spacebar> Debug responds: 13. Type: 90<enter>
Now type: e 86E1<return>
Debug responds: CD.
Type: 90<spacebar> Debug responds: 13. Type: 90<enter>
Now type: w<enter>, then q<enter>, then rename mme.zap to mme.exe.
If desired, the hidden file INFOCOM.CNR may now be deleted from the hard
disk, and the program will run without reference to it.
Now, for the second, and still incomplete method, which is unneeded at
present but may become important if Infocom becomes aware of the simple
method above and changes it to something more complex. As indicated
above, the two bytes in the file INFOCOM.CNR represent a nibble for nibble
encryption of the cluster number where INFOCOM.CNR resides. Although I
have not yet worked out the exact rules of encryption, taking the hex
digits of the cluster number from left to right, one adds plus or minus 4
to the first, plus or minus 2 to the second, plus or minus 4 to the third,
and plus or minus 7 to the fourth. Thus, it requires at most 16 tries to
create the correct contents of INFOCOM.CNR. The following examples may
eliminate some of these:
Cluster INFOCOM.CNR
------- -----------
2401 6648
3218 7051
4601 0448
4801 0A48
4901 0B48
4851 0A18
4A01 0848
4B50 0919
5919 1A50
5A19 1850
6317 215E
8619 C450
8B19 C950
8D19 CF50
9B5E D917
BA03 F84A
BF5E FD17
D05D 9214
The cluster number can be obtained with any utility capable of displaying
the directory contents, e.g. the Norton Utilities, Disk Toolkit, or even
debug. It is given by the 27th and 28th bytes (i.e. bytes 26-27) of the
directory entry for INFOCOM.CNR, which will appear early in the directory,
either between or just following other entries for the root directory. The
above encryption algorithm is applied, and the utility program then used to
replace the contents. Note that for the purposes of this exercise, the
bytes are taken as as, i.e. least significant byte first, not reversed to
give the actual cluster number.